home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Tech Arsenal 1
/
Tech Arsenal (Arsenal Computer).ISO
/
tek-20
/
ki6lo521.zip
/
ADDENDUM.DOC
< prev
next >
Wrap
Text File
|
1990-05-01
|
19KB
|
357 lines
Version 5.2x User Manual Addendum
CHANGES / ADDITIONS TO PREVIOUS V5.20
The following are a list of changes and/or addito\ions made to
version 5.20 since its release in January 1990. Some of these items
were not ready for release in verison 5.20 and others were cleanup or
adjustments to existing features. Each is noted as to whether it was
a change or addition, also where in the v5.2 manual the topic is found.
1) Program name change
All pages - Change
All filenames shown as LOG52.EXE should be changed to LOG521.EXE
All filenames shown as LOG52.OVL should be changed to LOG521.OVL
2) DATA FIELD ENTRY ENABLED TOGGLE FEATURE
page 20 - Addition - Data Input Field Status Selection Page
page 53 - Addition - Menu option "SET ACTIVE FIELD STATUS"
Some users were requiring that some of the non-required fields
on the Data Input form be disabled so it would speed up data entry
in their particular case. I decided to enable the user to turn off
(or on) any or all of the non-required fields in the log file. All
fields in the top box on the Data Entry form ARE required and can't
be turned off.
During initialization (or when v5.21 is first started and the
USER_LOG.CFG configuration file from v5.20 is detected), a screen
like the one shown below is displayed. Perform the functions as called
out in the accompanying text to toggle the fields ON to OFF or vice
versa. If a field is toggled to OFF when the ESCAPE key is pressed,
the 'OFF' label will appear in the area on the DATA INPUT form where
you would normally enter input data. It will appear there everytime
you select the ADD DATA option until you reset the field to the ON status.
To reset any or all fields, select the "SET ACTIVE FIELD STATUS"
option on the UPDATE USER DATA MENU from the FILE MAINTENANCE MENU.
Perform the required actions as before, saving with ESCAPE when done.
*****************************
DATA ENTRY FIELD STATUS
+-------------------------+
| 1 - NAME .......... ON | * All default to ON
| 2 - CITY .......... ON |
| 3 - STATE ......... ON |
| 4 - COUNTRY ....... ON |
| 5 - CQ ZONE ....... ON |
| 6 - ITU ZONE ...... ON |
| 7 - REPORT SENT ... ON |
| 8 - REPORT RECV ... ON |
| 9 - ANTENNA ....... ON |
| A - QSL SENT ...... ON |
| B - QSL RECVD ..... ON |
| C - MISC FIELD .... ON |
+-------------------------+
The window above shows the current status for ALLOWING data input to
the non-required fields of a log file. Pressing the NUMBER or LETTER
associated with the fieldname will toggle the ACTIVE status of the
field. If the status shows 'ON', you will be able to enter data in
that field when using the DATA INPUT form in the ADD QSO option. If
'OFF' is shown, the field will be disable till you reset it to 'ON'.
Set fields to desired status and press ESCAPE to save conditions and
EXIT to previous menu. NOTE : Default is all fields set to 'ON'.
***************************
3) 'HOTKEYS' OPTIONS - FUNCTION KEYS AND WHAT THEY DO
page 24 - Addition
F7:CALL - QUICK CALLSIGN CHECKING
Realizing that the ability to do a fast check for a callsign
on-the-fly was needed and had been noted by several v5.20 users,
I added this option for use in all areas of the program EXCEPT
while using the 'browse' function in the UPDATE LOG or QUERY modes.
Pressing F7 will give you a prompt as shown below. You will enter
the callsign to find (up to 12 characters).
ENTER CALLSIGN TO FIND (12 CHR MAX - <CR only> ABORTS) : ___________
Please note : If you enter only part of a callsign, say "VK4" or
"WB0" you will get ALL calls that start with the partial callsign.
If you had 20 contacts with VK4 stations and 5 of them were to VK4AA,
entering VK4 would find 20 contacts, while entering VK4AA would find
only 5. This is handy to see if you may have worked a prefix or area
already.
If any entries are found, a window is opened on top of whatever
you doing and ALL the matching QSO's are shown in the window, listing
the first 9 characters of the CALLSIGN, the date-time-freq-mode of the
QSO, the operators name (if any), QSL information and the country. If
more a definitive 'look' at any particular QSO data is required, move
the highlighted line to the QSO in question and press RETURN. Another
window is opened and all data for the QSO is shown along with any
COMMENTS. Press any key and the second window closes and you are back
at the list window. Select another or press ESCAPE to return to the
activity at hand before F7 was pressed. You may press F7 again for
another callsign or group of callsigns.
PLEASE NOTE : This is only a 'Viewing' option - no printing done here.
page 26 - Change
ALT-T key - TOGGLE THE AUTO DATE/TIME STAMPING DURING ADD QSO'S
The label for stating the status of the AUTOTIME feature was moved
from the right side of the menu to below the menu. It also shows
the status for both ON and OFF. The operation is the same as before.
page 27 - Change
ALT-U - TOGGLE CALLSIGN DUPING OPTION ON / OFF
The label for stating the status of the DUPING feature was moved
from the right side of the menu to below the menu. It also shows
the status for both ON, OFF, FULL or QUICK (see below).
page 28 - Addition
ALT-Y - TOGGLE DUPING MODE - FULL / QUICK
In order to allow faster duping without data retrival and copying
as done in v5.20, another DUPING mode was added for v5.21. This mode
called QUICK MODE (the original DUPING mode was renamed FULL MODE)
will allow the entry to be duped and you are warned if another call
of the same exact type (not like the F7 partial callsign entry
above) is found. If one is found, the following message is shown:
+----------------------------------------------------------+
| DUPE CALL - Press RETURN to keep, Any other for NEW call |
+----------------------------------------------------------+
Press RETURN, the callsign is kept and the data entry process
continues. Press any other key and the callsign is removed from the
input block and you are ready for another callsign entry.
For the FULL DUPING MODE, it works the same as duping in v5.20
except if you select to not search for more matching entries, the
current callsign is kept and the entry process continues on to the
date field.
page 31 - Change
Example of Data Entry Form
The below diagram shows the new DUPING mode label placement. The
status of the DUPING is shown at the 'FULL' location. Pressing ALT-Y
will toggle the DUPING MODE while DUPING is ON. It has no effect while
DUPING is OFF.
F1:HELP F2:TONE F3:KEYS F4:TIME F5:PRFX F6:MODE F7:CALL F8:DBF ADD
+--------------------------------------------------------------------+
| QSO INFORMATION |
+--------------------------------------------------------------------+
| Callsign : [ ] Duping : FULL (Alt-Y) |
| |
| Date (M/D/Y) : [12/10/89] Time (Zulu) : [1930] |
| |
| Frequency : [ 0.000 Mhz] Mode : [SSB] |
| |
+--------------------------------------------------------------------+
page 41 - Change
CONNECTING THE INDIVIDUAL CONDITION STATEMENTS
Once the field name, compare symbol and target value have been
entered, you will be shown another selection window asking if you want
to 'connect' this statement to another logically. Remember the pre-
vious example where we used an 'AND' and an 'OR' to connect
statements. You will be shown this window:
+-------------------------------------------------------------------+
| Previous condition AND this condition must be TRUE for match |
| Previous condition AND NOT this condition must be TRUE for match |
| Previous condition OR this condition must be TRUE for match |
| Previous condition OR NOT this condition must be TRUE for match |
| No more entries needed in this condition set |
+-------------------------------------------------------------------+
Now there are 5 choice here instead of 3. The menu has been increased
in size and text to help make the decision about which one to use. The
process of 'connecting' the statements together is the same as in v5.20.
******************************************************
Additional information and clarification on the use of
QUERYING THE LOGBOOK FILES
Several users have called stating that the new v5.2x query system
seems to be slower than the v5.11 query interface. Well, it is if you
use the data access time as the only reference to performance
improvement. In the following text, I will explain why the the new in-
terface seems slower and what can be done to make it perform to the
maximum capability.
To BUILD or not to BUILD :
In v5.2x, you have the capability to build a 'filtering' string
or condition statement which could be saved to a disk file for later
recall. The condition statement could be a simple comparison or an
elaborate 'filter' to ignore all but a specific few records. Whether
to build a string or not is up to the user. If it is not built, then
the program will react in 1 of 2 ways.
Condition #1 - If entering the QUERY menu from the MAIN Menu and
having not built a previous condition statement once in the QUERY
menu, if the VIEW option is selected then ALL records will be shown on
the screen. Since there is no condition to limit the access to the
records, all present records are displayed in the ordering you select
from the 'INDEX BY .... ?' menu.
Condition #2 - If a condition statement has been previously built
and another is NOT built prior to VIEWING and if the statement pre-
viously built wasn't 'ALL' (see manual for meaning of 'ALL'), then the
display will be limited to those records that 'pass-thru' the filter
(i.e. match the condition statement).
I would strongly advise that for casual 'browsing' (VIEWING) that
the condition statement be 'ALL' if one is to be built. Also that the
INDEXING order be that of a natural logbook (i.e. chronologically by
DATE and TIME), since this will help group all daily contact and will
correspond with your recollection of events and QSO's easier.
***************************
Remember that F7 is also available for
FAST checking of callsigns in log file.
***************************
Also be aware that if the condition statement is too limiting
(many facets to match) that the system will take longer since it must
check each record field against the matching statement for any pos-
sible match. In a log of several thousand QSO's, you could setup a
condition that would possibly take several minutes to search through
all the records. To avoid this type of delayed searching, select the
index that closest matches the type of data you will be looking for.
Select 'INDEXED by COUNTRY' if you are going to be limiting your found
records by country name. If there is not close index or if you are
unsure, select NO index and let the log go in natural order.
Using the F3 FIND key :
Using the F3 find key in the wrong place at the wrong time will
not hurt anything, but it could eat up a lot of valuable computer
time. For instance, if you are searching for all records that have the
country equal to, say ENGLAND, and pressed F3 for a quick find of a
callsign that is not in ENGLAND, then some strange things can happen.
Let me clarify the last statement. The strange things are a result of
you forcing the program to try and do something it is easily capable
of doing, but during this stage of the game, it is somewhat taxing on
the program's performance.
What could possibly happen is this. If the program finds the
callsign, it will go to that record position in the log file, put the
QSO data on the query display screen at the line where the highlighted
box was at when the quick find was requested (F3 pressed) and then
continue from the callsign matching record and display records that
originally matched the condition statement in use, till the screen is
full or the end of the log file if found, which ever comes first. If
you have several thousand records and just searched through and
filled the screen, which could take a little while depending on the
complexity of the condition statement, the program has to now research
the log file filling the screen again. This is a repeat of time already
used and hence a degradation of system performance. By limiting the use
of the F3 key, whose originally intent was a quick way to jump around
in a 'full' browse (remember 'ALL'), you can eliminate wasted time and
speed up performance.
Also, if the record in which the callsign was found does NOT
match the condition statement, then when the display is scrolled to
cause that record to leave the displayed area, scrolling back to that
record will cause THAT callsign record data to NOT be displayed. It
doesn't match so therefore it is not displayed. It is displayed the
first time simply because we forced it to be displayed by using the F3
FIND function. Once it is removed from the screen, it is not displayed
again unless you repeat the F3 action.
To summarize, a few key points and some Do's/Don'ts are listed below:
1) Use 'ALL' as the condition statement for casual browsing.
2) A complex condition statement will most likely cause the sys-
tem to slow down in searching since more fields are involved in
the search. With a slow system and many entries, the system could
effectively slow to a crawl.
3) If the system seems to be stuck or not responding as you think
it should, DO NOT keep banging on the keyboard. Instead let the
system 'catch up' to a full page of records on screen or allow it
to come to a point where it is waiting on you, then press ESCAPE to
leave that browse and rethink your query statements. Are they too
limiting for the expected speed and performance.
4) Selecting an INDEX other than DATE and TIME (natural order)
will cause the search time to increase. You may avoid this by
matching, as close as possible, the INDEX key field to the data
being searched for.
5) When 'browsing' and searching for callsigns, etc. with F3,
select the DATE/TIME index for a log file and the PREFIX index
order for the DX INFO file, and have the condition statement set
to 'ALL'. This will give the maximum speed performance of your
system.
6) Larger logs take longer to search and if a complex condition
statement is applied, this time could be several minutes, depending
on the log size and what you are looking for.
7) For maximum time use, do most of your querying while not
operating since query searches can be quite time consuming. Use F7
for on-the-fly entry checks.
8) Whenever searching for matching keywords in the COMMENTS
field, be prepared to allow a larger amount of time since each
word or phrase in each COMMENTS field must be compared to the
condition statement.
9) Don't expect a 4 Mhz 8088 machine with a slow hard disk to be
a optimum performer in a large query situation. Any machine will
only do its best. A 4mhz 8088 can't possible give the same searching
performance as a 20mhz 80286 can!
10) Experiment with different query conditions and record the
results for later comparisons. You will discover what situations
to avoid with your system's setup.
Version 5.2x query interface is very powerful. It will allow you
to find almost any data configuration you will need in ham radio
logging. The performance level is many times that of v5.11 and hence
there may be a few situations in which the previous version has the
edge when it comes to speed. But don't be fooled in to thinking that
because v5.11 does something faster that it was a better program.
Many, many hours of design and testing/tweaking have gone into v5.2x
and I hope that everyone can master the query interface to obtain the
maximum performance from it. It requires a small amount of experience
to really benefit from it. Besides it never hurts to learn something
new.
If you still are having problems with the performance
expectations, send me a copy of you log file and a letter of what you
are trying to do. I will take a look at it and get back to you with
help.
73's Gene KI6LO